The present invention relates generally to methods for linking different computer languages, and more specifically to a method for calling an interpreter language procedure from a compiler language procedure.
In computer programming it is the usual practice to call procedures described in an interpreter language such as C language from procedures described in a compiler language such as Lisp in order to utilize user's existing compiler-language libraries or modules in an interpreter-language environment or take full advantage of different languages when describing a high-speed computation program in FORTRAN. In this foreign language call, two types of user interface are available. With the first type, the interface uniquely assigns a function to a particular foreign language when the latter is called and receives a return value if there is one. This method is extensively used for operating systems in which foreign language procedures are dynamically linked. Although satisfactory for implementers, this method shifts the burden of programming to the user's side by frequent needs to use unnatural descriptive codes. The second type of interface is one in which the user is requested to identify the type of a foreign language to be called and the types of arguments and return values. The latter represents a more natural way of foreign language calling than the former and has met with a wide reception for calling a foreign language procedure from within an interpreter language procedure.
With the aforementioned foreign language calling methods, arguments are passed to a foreign language procedure to invoke some actions and return values are received, with all the steps involved being run in a closed loop within the foreign language procedure.
In order to increase the flexibility of processing and to realize high-level utilization of computer programs, proposals have been made to call an interpreter language procedure from within a foreign language procedure which has been called from that interpreter language. As with the current foreign language call, two types of user interface are available for calling a function described in an interpreter language. With the first type of the proposed interface, a compiler language procedure is available for users to call interpreter language functions. With the second type of such user interface, the user in his own foreign language procedure describes a reference to an interpreter language function as if it were described in a compiler language, defines the interpreter language function before the foreign language procedure is dynamically linked within the interpreter, and identifies the type of the foreign language to be called and the types of arguments and return values.
One example that implements the first type of the proposed user interface is a function lisp-call (index, arg1, arg2, . . . , argn) which is provided by a Lisp processing system to allow it to be called by a C-language processing system. The index is the identification of an element in a listing (address table) of addresses of the Lisp functions to be called and the arguments are ones which will be passed to the Lisp functions. The user is instructed to use the lisp-call function to describe a C-language function to call a Lisp function in a compiler and then invoke the Lisp and dynamically solve the references in object files obtained by the compilation. This dynamic linking is done by the use of a process which dynamically calls a static linker provided by an operating system. The user then defines the Lisp functions to be called by the lisp-call function and stores their addresses into the address table. The identification of an element in the address table is passed as an argument to the called foreign language procedure to derive a function address listing corresponding to the address table. One disadvantage of this interface is that the user is always required to use the interpreter function which is the only channel, or window through which a foreign language call is established. Another disadvantage is that the user must be constantly aware of the internal states of the interpreter since the first argument of the window function is an element identifier of a management list of the interpreter.
The second type of the proposed user interface is implemented by a Lisp function define-foreign-entry in which are given the storage area name of the foreign language procedure that references to the Lisp function, arguments and return values. By performing a dynamic linking, the Lisp function is called from a foreign language procedure using the same function name. Since the storage area name of the foreign language procedure must be provided to make reference to the Lisp function to execute the define-foreign-entry function, the user must be constantly aware of the storage area of the foreign language procedure when using various functions. Another disadvantage is that a substantial amount of overheads is needed for management of storage areas.